What's a good practice for storing large binary blobs (e.g., raw images) associated with a point, given payloads are meant for structured metadata?

The standard practice is to store the blob in an object store (S3, GCS, Azure Blob) or a dedicated content store, and put a reference to it in the Qdrant payload. The reference is typically a URL, an object-storage key, or an opaque content ID. The payload then holds only the metadata needed for filtering, ranking, and retrieval, and the application resolves the reference when it needs the blob. This keeps the payload small, which keeps the payload index small, the memory footprint small, and the response size small. It also lets the blob be served from a CDN or a dedicated content service with its own caching, access control, and lifecycle management, which is a better fit for large binaries than a vector database. The pattern is the same as storing PII: keep the vector database for what it is good at (vectors and metadata) and put the large or sensitive content elsewhere.

The mechanism that makes this work is that Qdrant is optimized for small, structured payloads that can be indexed and filtered. Large binary content is not indexable, cannot be filtered on efficiently, and dominates the storage and memory cost. If you store an image in the payload, every payload read during a filtered query has to read the image bytes (or a pointer to them) and every response that returns the payload has to serialize and transmit the image. The result is slow queries, large responses, and a collection that uses far more memory than necessary. Storing a reference avoids all of this: the payload holds a short string, the index stays small, and the blob is fetched only when the application actually needs to display or process it. The trade-off is that the application now has two stores to manage and must handle the case where the reference points to a missing or inaccessible blob. In practice this is a small cost compared to the performance benefit.

The trade-off is between simplicity and performance. Storing the blob in the payload is simpler - one store, one API - but it degrades every aspect of the system's performance and cost. Storing a reference requires the application to manage two stores and to handle the failure modes of the external store, but it keeps Qdrant fast and small. The common mistake is to store base64-encoded blobs in the payload because it is convenient, which inflates the payload by 33 percent and makes every query slower. The second mistake is to store a reference that is not stable - for example, a URL that changes when the blob is moved - which breaks the link between the point and its content. The third mistake is to store the blob in a local filesystem on the Qdrant node, which defeats the purpose of an object store and makes the node stateful in a way that complicates scaling and recovery. The fourth mistake is to forget to set up a lifecycle policy on the object store, so blobs accumulate forever and cost more than they should. Version note: Qdrant's payload storage and index types have evolved, but the principle of keeping payloads small and structured is version-independent. Some features (e.g. full-text indexes) assume text payloads, and very large text payloads are as problematic as binary blobs.

Version-dependent: the payload storage and index types have changed across Qdrant releases, but the best practice of storing references rather than blobs is version-independent. Some versions support on-disk payload storage, which reduces the memory cost of payloads, but it does not eliminate the cost of large payloads - it moves it to disk. If your payloads are large because of legitimate text content (e.g. chunk text), consider whether the text needs to be in the payload or whether a reference to a separate text store would be better.